PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.61

Text File | 1988-06-18 | 47.4 KB | 1,150 lines | [TEXT/ttxt]

Usenet Mac Digest     Thursday, May 12, 1988         Volume 4 : Issue 61

Today's Topics:
     Word Perfect for the Macintosh 1.0 (2 messages)
     V
     Entertainment and bugs from Claris
     Generic SCSI tools.
     Translate PostScript to TeX?
     Flex problems
     Re: VersaTerm 3.2 (Was: VT100 emulators)
     VT220 Terminal Emulator Wanted
     CD-I revisted - Tale of the Uninvited
     Re: VT220 Terminal Emulator Wanted
     FullWrite Professional 1.0: First Impressions [long]
     FullWrite Color Menus
     Re: FullWrite on shelves (2 messages)
     Re: Mac Security
     Re: Programmer's Extender vs. MacExpress...
     PrintMgr Bug?
     Re: MultiFinder switch bug with custom WDEFs (3 messages)
     Mac Lint
     Turbo Pascal (2 messages)
     WDEFs in MPW?
     LSC Glue code

----------------------------------------------------------------------

From: [e-mail]
Subject: Word Perfect for the Macintosh 1.0
Date: 5 May 88 17:39:00 GMT

Word Perfect for the Mac is a nice program for those who also use it on
other machines (like IBM pcs, Vaxes, etc).  But I don't think it was
quite ready for release.


Word Perfect Mac bugs, annoying features and weirdnesses:

1. If you have an IBM WP 4.2 doc with foreign characters, and open in WP
Mac, you get the foreign character with the same ascii code, eg an ash
(ae ligature) becomes e umlaut. (code 145).  If you convert the doc back
to 4.2, you get the same characters as on the Mac, eg e umlaut stays e
umlaut I presume the difference comes in that Saving As 4.2 format goes
through some type of conversion, while opening a 4.2 simply opens it.
Someone named Kent from WPCorp is supposedly looking into this.

1a. By the way, why should we have to tell it creator and type to read
in WP 4.2 file?  Doesn't it know who it is?

2. While in WP, switch to Finder or other application.  Partially cover
the title bar of WP with another window, then move window away.  Title
in bar in messed.

3. Command W cycles through open windows, Command K is Close.

4. Start with blank doc.  Turn on Bold (or any other style, by any of
the documented means) and note how scroll box jumps.  Well, that's
somewhat explainable by the fact that a code has been inserted, but if
you click in the grey area to move the box back to the top, your code
gets deleted!  This doesn't happen for all kinds of codes, but it does
for all styles.  In general, the scroll bar frequently acts strangely.

5. You cannot resize windows while in reveal codes, but the zoom box
does work.

6. You can tell WP where to look for dict, thes, and macros, but help
file
 must be in same folder (or desktop) as program.

7. You cannot use the mouse in the reveal codes window.  Cursor can only
be moved by doing things in the upper window or by arrow keys.

8. Clearing the ruler (via the little "x" box) does not revert column
settings.

9. Searches go forward or back, don't wrap.

10. When hierarchical menus are "torn off" the secondary menu choices
are sometimes numbered, sometimes lettered.  Is it just the Merge codes
submenu that is lettered, to be consistent w/ WP 4.2?

In general, the program has some nice features, but suffers in greatly
implementation from it other machine origins.  To my mind, FullWrite has
a far better user interface.  No I haven't gotten the release version
yet, but I check my mailbox eagerly each day!

By the way, one thing I can't complain about re: Word Perfect.  They
have the best customer support in the business.  Don't hesitate to give
them a call if you have a problem.
--
Linda Iroff
Humanities Computing Center
Cornell University
[e-mail]
[e-mail]


------------------------------

From: [e-mail] (Paul Molenaar)
Subject: Re: Word Perfect for the Macintosh 1.0
Date: 6 May 88 09:53:07 GMT
Organization: Host: NIKHEF Organization: Personal Computer Magazine, Holland

>1. If you have an IBM WP 4.2 doc with foreign characters, and open in

Not in my april 12th 1988 version. 'Foreign characters' are converted as
they should be...

>1a. By the way, why should we have to tell it creator and type to read
>in WP 4.2 file?  Doesn't it know who it is?

The File Management option is a horror. Why should WordPerfect give the
user access to the bundle, hidden, protect etc. bits? When files are
imported from an MS-DOS machine, there has to be a way of changing type
and creator (since they are not automatically appointed on import) but
WordPerfect Corporation should have made that a single button-action.


>2. While in WP, switch to Finder or other application.  Partially cover

Again, not in april 12th issue

>3. Command W cycles through open windows, Command K is Close.

Close window has, as far as I know, only recently been assigned the
cmd-W shortcut 'officially'. Cmd-K is a drag. I used ResEdit to change
it.

>9. Searches go forward or back, don't wrap.

I think that's a joy...

[Some mention of other bugs deleted. Most of them also present in april
12th version]

------------------------------

From:
Subject: V
Date: 6 May 88 09:53:07 GMT

        "Just checking the walls"
                - Basil Fawlty -


------------------------------

From: [e-mail] (ephraim vishniac)
Subject: Entertainment and bugs from Claris
Date: 5 May 88 14:20:21 GMT
Organization: Thinking Machines Corporation, Cambridge, MA

I got a box from Claris this morning with MacPaint 2.0, MacWrite 5.0,
and MacProject II 1.0.  MacPaint's new features look good, MacWrite's
new features are amusing, and MacProject has at least one cosmetic bug.

MacWrite's biggest new feature is a "built-in" spelling checker.  Sort
of.  It *does* check spelling, but it's *not* built in.  It's just kind
of tacked on.  Here's what happens when you check spelling:

        1. The spelling checker resizes the active window so that it
           doesn't overlap the area where the spelling window will
           open.  Automatic window resizing?  Not exactly Macish, but
           it has to do this because (as a tacked-on kluge) it has
           no control over the scrolling of the main window.  It
           insists on placing its own window at the bottom left of
           main screen, even when there are acres of unused screen
           available.

        2. It opens the "Find" dialog offscreen, where the user shouldn't
           see it.  It has to do this because (as a tacked-on kluge)
           it can't locate words in the document any other way.
           "Offscreen" is only a short distance to the left of the
           main screen, which happens to be onscreen for the second
           monitor of the system I was using.  Very tacky.

        3. It does a "Select All" and "Copy" to get the text of the
           document into the clipboard.  Again, it doesn't have any
           direct access to MacWrite's data structures, so it can't
           get the text any other way.  As a side effect, this wipes
           out the clipboard contents without warning.  Ouch.  Do a
           "Show Clipboard" before checking spelling to watch this
           action.

        4. It does the actual checking against the clipboard contents,
           using the Find dialog to locate and highlight words in the
           real document.  It's not smooth, but it works.

MacProject II is much less entertaining.  For a simple bug demo, try
this:  Display the top left portion of one of the small samples on your
19" monitor.  You'll have all of page one and part of page two (which is
blank) on the screen.  Use the layout menu to adjust the chart size down
to one page.  Except for the portion that was covered by the chart size
dialog, page two remains white until the next time the whole screen is
redrawn.  The part that was covered turns to desktop pattern, just as
the rest of the page should.  No real problem here, but it looks bad.
--
Ephraim Vishniac                                          [e-mail]
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214

     On two occasions I have been asked, "Pray, Mr. Babbage, if you put
     into the machine wrong figures, will the right answers come out?"


------------------------------

From: [e-mail] (Richard W. Fortier)
Subject: Generic SCSI tools.
Date: 3 May 88 20:04:29 GMT
Organization: Epoch Systems, Marlboro MA

I'm looking for source and/or binaries for SCSI formatters and drivers
for the Mac II.  We have lots of different types of SCSI drives in
house, so I need software that is generic as possible; it must read
parameters from the drive(s) rather than wiring in constants; in
particular, many of the driver's and formatters floating around wire in
drive capacity.

Drivers must be able to deal with synchronous-mode drives, and should
handle drives which want to disconnect and reconnect.

As I said, we have many drives but two in particular I'd like to handle
are the CDC Wren IV (CDC 94171, 312MB) and the Fugitsu 2246A (130MB).

Any information anyone has on making these work with A/UX would also be
appreciated.

Rich

--
---
Richard W. Fortier, Epoch Systems Inc. [phone]
313 Boston Post Rd. West, Marlboro MA 01752
{linus!alliant, harvard!cfisun}!palladium!rfortier


------------------------------

From: [e-mail] (Peter A. Krupa)
Subject: Translate PostScript to TeX?
Date: 5 May 88 21:45:37 GMT
Organization: The Pennsylvania State University - Computation Center

Does an application exist to convert PostScript laser printer output to
TeX or imPRESS (Imagen 8000) language?  I myself, and now my boss, are
interested in downloading our Mac printouts to the lab's laser printer.
Any information you could provide would be greatly appreciated.

If such an application doesn't exist, is there anyone who's interested
in helping me to develop it?
--
Spiny_Norman (alias Peter A. Krupa)
ksn@psuvm (till the end of the week)
ksn@psuarlb (year round)


------------------------------

From: [e-mail] (Stephen D. Keller)
Subject: Flex problems
Date: 2 May 88 20:55:38 GMT
Organization: Wheaton College, Wheaton Il

     I love the screensaver FLEX, but it does not allow me to download
     in the background.  I have tried downloading files with the
     "enable background tasks" button checked and unchecked.  When
     checked, the download fails; when unchecked, the download is
     interupted when the screen dims, and continues when I terminate
     the screensaver.  Has anyone else run into problems with this?
     Can it be fixed in the 'next release?'  I have used AutoBlack
     without any problems at all, so I guess I'll go back to using that.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steve Keller                                                  Wheaton College
ihnp4!wheaton!skeller                                             Wheaton, IL


------------------------------

From: [e-mail] (Thomas Fruin)
Subject: Re: VersaTerm 3.2 (Was: VT100 emulators)
Date: 5 May 88 22:24:54 GMT
Organization: uvabick


Jeff Meyer writes:

 > 3.2 also has [...] Remote file transfer (haven't read up on this, but
it
 > seems that if you have a Mac running unattended with VersaTerm 3.2
and a
 > modem set up for auto answer, you can call up from another Mac and do
 > file transfer using this.

This is also potentially very dangerous!  I've just been reading the
specs, and it turns out _anybody_ can dial into your Mac, and download
just about everything on your (hard) disks.  VersaTerm does NOT prompt
you for a pass- word, and you can even use wildcards when downloading.
Since you can type any pathname, the remote volume is up for grabs.

You can turn off this option by unchecking the 'Enable Remote File
Access' option in the everexpanding Extras dialog, but hear this: by
default (right out of the box) this option is ENABLED...

OK ok, dialing in still requires a modem connected in auto answer mode,
but this is still leaving the back door wide open.  I recommend
everybody turning this option OFF now, including Lonnie Abelbeck if he
is listening.

One last thing: the caller can also upload.  I haven't checked yet if
that lets people overwrite any file on your remotely accessible volume.
It would be the most silent way to install a virus :)

-- Thomas Fruin

   [e-mail]                  University of Leiden
   [e-mail]                   University of Amsterdam
   hol0066.AppleLink
   2:512/114.FidoNet                     The Netherlands


------------------------------

From: [e-mail] (Kevin Kinnear)
Subject: VT220 Terminal Emulator Wanted
Date: 6 May 88 13:32:16 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois

A friend of mine is looking for a terminal program for the Mac that
emulates the DEC VT220 terminal.  He is connecting to a VAX running VMS
and would like to emulate the same terminal that he uses at work.  I
think function key compatibility is important, too.

This is important-- if he can't find this capability on the Macintosh he
may decide to buy an IBM compatible PC (shudder) instead!
--
<Kevin Kinnear
[phone]


------------------------------

From: [e-mail] (Michael S. Czeiszperger)
Subject: CD-I revisted - Tale of the Uninvited
Date: 6 May 88 20:08:07 GMT
Organization: The Ohio State University Dept of Electrical Engineering

[This contains somewhat interesting stuff about the latest development]
[in home entertainment.  Please forgive the somewhat boring intro     ]

I got a call this week from a CD-I developer, who claimed he got my
number from a friend who reads USENET.  He was all excited about telling
me the latest happenings with CD-I, except he  thought us USENET chaps
didn't know anything about CD-I and proceded to  run down the entire
last two years of CD-I history.

After I got it through his head that the green book standards and the
formulation of American Interactive Media were by now well-known events,
he managed to explain who he was and why he was calling.  I think his
last name was Feldman, although I'm not sure because he talked so fast.
He claimed to be an employee of the company that makes the computer
games "Deja Vu" and "The Univited", and that he was *at this very
minute* working on CD-I versions of these games.

He went on to claim that there were about a hundred companies working on
CD-I titles, and that most of the titles weren't games, but a new kind
of entertainment.  For instance, there is one disk that is a  home audio
mixing session.  The CD-I disk contains the raw tracks from a well known
rock group's recording session, and the home user gets to mix down and
arrange the tune any way they like.  It was mentioned in Keyboard
magazine that some of the high end players will include MIDI outputs, so
the home recording enthusiast could use his home recording setup.
Theoretically one could record the MIDI output from the CD-I disk
directly into a MIDI sequencer and then re-arrange the whole tune, or
examine how all the licks were put together. A written score of the
album could even be generated from the MIDI output, so the hobby
musician could have an *exact* musical notation of the original music,
not the cheesy version featured in those books.

One thing we talked about was the present mis-conception about the
possibilities of interactive entertainment. Some people are unable to
comprehend anything interactive that doesn't function like the  Dragon
laserdisc game that was out a couple of years back.  In that game, the
user could only decide between left, right, and straight, and the game
just jumped between tracks on the laserdisk. This way of operating is
not in any way representative of CD-I, or of interactive media in
general.

For instance, the CD-I version of Dark Castle will function *exactly
like the regular Dark Castle*, except for a bunch of added features. For
another thing, it will be in full color, and the audio will feature
longer, more complicated, better recorded sound effects.  Beyond that,
it will be try to be more than just a computer game.  If the user just
wishes to watch, for instance, Dark Castle will cease to be a game, and
will become more like a movie, presenting a story with dialog,
characters, and a plot that takes place on the backgrounds of the game.
As you can imagine, THIS IS NOT ANYTHING LIKE DRAGON'S LAIR.  Not one
bit.


About the players themselves.....

The manufacturers of CD-I players have pledged to make the first units
cost under $1000.  There are rumors that base units with no extra
features could initially cost as low as $750.  Philips is getting  ready
right now for CD-I by including a CD-I port on all of their regular CD
Audio players.  If you've purchased a Philips CD player in the last two
months it probably has this port.  When CD-I finally hits in about a
year, Philips will sell a cheap expansion box that contains the heart of
the CD-I system.

The basic units will come with:

        1. The ability to play regular CD audio disks.
        2. A video output to hook up to your TV.
        3. A joystick.

One of the problems with using CD's as a storage media is that it's
impossible to write on the darn things.  How are people going to store
data such as their highest Dark Castle scores?  The players themselves
will have 16k of battery backed memory, that should take care of a small
amount of data.  An alternative is to include an extra video output so
that the player could record the data directly to videotape.  Assumming
that the kind of people that would by CD-I players are the same kind of
appliance happy people that buy VCR's, this should a workable solution.
:-)



Just bringing the USENET community the latest news.....

-czei

--
Michael S. Czeiszperger         | "The only good composer is a dead composer"
Systems Analyst                 | Snail: 2015 Neil Avenue         (614)
The Ohio State University       |        Columbus, OH 43210          292-
cbosgd!osu-cis!accelerator.eng.ohio-state.edu!czei                    0161


------------------------------

From: [e-mail] (Herb Poppe)
Subject: Re: VT220 Terminal Emulator Wanted
Date: 6 May 88 20:22:22 GMT
Organization: Scientific Computing Division/NCAR, Boulder, CO

White Pine Software has several DEC terminal emulators for the Mac:

        Mac220  VT220 emulation  $129 (retail)
        Mac240  VT240 text and graphics emulation  $199 (retail)
        Mac241  VT241 color text and graphics emulation  $299 (retail)

        White Pine Software, Inc.
        94 Route 101A
        Amherst, NH 03031
        603-886-9050

I do not use any of these products nor do I know anything about White
Pine Software other than that they recently have established a very
close relationship with DEC and are planning to bring out an X Window
System server that runs under the MacOS at the end of the year.
--
Herb Poppe      NCAR                         INTERNET: [e-mail]
[phone]  P.O. Box 3000                   CSNET: [e-mail]
                Boulder, CO  80307               UUCP: [e-mail]


------------------------------

From: [e-mail] (Christopher Chow)
Subject: FullWrite Professional 1.0: First Impressions [long]
Date: 7 May 88 01:04:33 GMT
Organization: Cornell Theory Center, Cornell University, Ithaca NY

Recently, the computer store which I work at just go in several copies
of FullWrite Professional 1.0.  Since I had really liked the demo
version of FullWrite, I had looked forward to playing with the release
version.

Unfortunately, it appears that FullWrite 1.0 has a few problems:

One of the first things I did when a Word Perfect rep came to campus to
demo the alpha Word Perfect a couple of months ago was to test Word
Perfect's ability to work with large files.  Essentially what I do is I
start with a short document, and then repeatily do:
        select all, copy, paste I generally try to get a document greater than
50 pages to play with it. Naturally, this was one of the first things I
did with FullWrite.  Well, I was working on a 2MB Mac II under normal
finder (6.0), and everything was fine (except a bit slow) at 30 pages,
but FullWrite crashed when I attempted to go from 30 -> 60 pages.  At
least it could have told me that it didn't have enough memory to do the
paste instead of just crashing an unsaved document.

Later on that day, someone came in and inquired about FullWrite's
ability to do outlines.  After he left, I decided to explore outlining a
bit further by myself.  What I did was I took "Newsletter" example file
from FullWrite and made it into an outline with three main topics:
FullWrite, dBase Mac, and FullImpact.  None of the original text was
used in the headlines as I typed in my own headlines.  Each main topic
had a few subheading.  Again, the subheadings are original text:  all
the original text encompassed by the outline was in the outline body.

Initially, I was impressed.  The outlining made sense and seemed pretty
useful.  After playing around for a while, however, I decided to see how
well FullWrite could handle changing the outline structure (and all the
associated text in the body).  Well, it crashed (deadlocked) pretty
easily. All I had to do was to swap the first two main topics a few
times, and then swap the third main topic with either of the first two
and then the watch cursor would continue to spin forever.  Or at least 2
minutes, at which time I gave up and hit the interrupt button.  This
happened both under Multifinder (with the application partition
increased to 1350K) and under Finder.  It appears to be a bug in dealing
with larger outlines as a trivially small outline (all headlines and
body consisting of one line) I constructed did not crash.  I was also
able to get FullWrite to deadlock on another large outline I created
from importing an MS Word 3.01 file.

Now back to FullWrite's handling of large files:  Although my first
attempt at creating a large file crashed FullWrite, I decided to try
again. Initially, the document I copy-pasted contained some graphics
created by FullWrite.  This time, I choose to import an MS Word 3.01
file which only contained text.  Using the copy-paste routine, I built
up the file to about 75 pages.  With large files, FullWrite can
sometimes take a long time to scroll, especially if you take the
elevator box and just plop it down somewhere in the document.  I then
tried spell checking the document, which worked well.

However, there is a problem.  During a long operating, FullWrite just
moves the watch hand on the mouse cursor:  unlike MS Word, it does not
give you a %complete indicator so you don't know if the work you asked
for is being done.  Note that this means the only way you can detect a
deadlock is to wait, and wait, and wait...  The spinning watch is no
indication of useful work being done, since during both the initial out
of memory crash, and the outlining deadlocks the watch was spinning.

Aside from what I mentioned already, I also found a few miscellaneous
bugs: On a Macintosh II, FullWrite doesn't use color resources
correctly.  I.e., when displaying an icon in a dialog, even if you have
installed a cicn for the icon FullWrite will still use the plain b/w
icon.  If you changed the window coloring scheme (I make the title bar
lines blue) FullWrite still uses the normal black and white lines.
Selected text is covered with black instead of the color choosen by the
"Colors" cdev.  All this mismanagement/ignorance of color resoures is
inexcusable since the FullWrite programmers obviously knew about color
quickdraw:  If you select "About FUllWrite", the Aston-Tate Icon is in
red!  Finally, there is a non-Mac II specific miscellaneous bug which I
found:  FullWrite does not allow Larry Rosenstein's (sp) ApplicationMenu
INIT to work.

So, how long until version 1.0.1?
--
Christopher Chow
/---------------------------------------------------------------------------\
| Internet:  [e-mail] (128.84.248.35 or 128.84.253.35)   |
| Usenet:    ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow    |
| Bitnet:    [e-mail]                                           |
| Phone:     [phone]   Address: 7122 N. Campus 7, Ithaca, NY 14853   |
| Delphi:    chow2            PAN:  chow                                    |
\---------------------------------------------------------------------------/


------------------------------

From: [e-mail] (Jeff Shulman)
Subject: FullWrite Color Menus
Date: 11 May 88 14:38:29 GMT
Organization: Schlumberger-Doll Research, Ridgefield, CT

As has already been noted by someone, FullWrite does not use color menus
even if you set them up on your Mac II with the Kolor CDEV.  The reason
for this is twofold:  First, they supply their own mctb resource.  An
applications own mctb resource will override (rightly so) the global
mctb put in the System file by Kolor (same with all other color
resources).

Thus, you might think removing this resource from FullWrite will give
you color menus.  It does, sort of.  You will get your menubar colored
and the items in the Apple menu.  However, the items in the other menus
will remain B&W.  This is due to the non-standard MDEF the use to handle
their menus.

Their MDEF (as also already noted by someone) does not follow the Apple
interface guidelines by putting triangle arrows at the top and bottom of
long scrolling menus (such as the Font menu).  One thing in their favor
though, their menus do scroll much faster than Apple's.

                                                        Jeff
--
uucp:     ...rutgers!yale!slb-sdr!shulman
CSNet:    [e-mail]
Delphi:   JEFFS
GEnie:    KILROY
CIS:      76136,667
MCI Mail: KILROY


------------------------------

From: [e-mail] (Chuq Von Rospach)
Subject: Re: FullWrite on shelves
Date: 8 May 88 23:39:19 GMT
Organization: Fictional Reality

>I hope it was worth the wait.

I think so, so far. I picked up my copy at ComputerWare for about $260.
I haven't played with it a lot yet, but I have pored through
documentation and done a little prodding and pushing, and I think I'm
going to really like Fullwrite.

It's definitely not perfect, but it has the power of Word 3.0. It's also
a very intuitive program. As you read through the manual, you start to
realize just how intuitive it is (in many ways, you don't need to read
the manual. For a program of this power, that says something).

There are some areas that I've flagged as things to be aware of. Some of
these are plusses, some minuses. This isn't in any particular order
(yet):

+ The documentation is generally well written. There are two volumes: a
        learning guide and a reference manual.

- However, the manual does not have a tutorial. There are a bunch of
samples
        on the disk, but no structured tutorial introduction. The learning
manual is
        basically a "take a look at this" and assume's you're poking at it
        on your own. A structured tutorial would help the startup time.

- The manual is incomplete in some areas. It mentions, but never
explains,
        stationery (read-only documents that are used as templates). It
        barely mentions something called background files, which are (I
        think!) used to import stuff like EPS files into stationery. I
        really don't understand what they do, how, or why. I'm hoping that
        the examples shipped with the program explain it, since the manual
        ignores them. This looks to be, also, the only way to get postscript
        code into your documents. Hope I'm wrong on that one.

- Style sheets are functional, but more limited than Word 3.0. No "based
on"
        or "next style" options. Styles seem to be additive, also: if they
        set up a bold/italic style and impose it on underlined text, it
        comes up bold/italic underlined.

+ They've implemented something called a variable. A more generalized
flavor
        of the various page/date/time icons in Word headers. you can define
        your own, too (I'm not sure why yet, though). One that I find
        missing is the # of words (variables exist for pages and
        characters).

- You don't seem to be able to save drawings from the draw layer
        independently. You can grab them via the clipboard, but you could
        almost obsolete the need for a separate drawing program if you could
        save it conveniently.

- Startup is rather slow, and it brings up a copyright message every
time.
        Not really bad, but it stays up long enough to be irritating, and I
        almost get the feeling AT has a wait loop in the initialization code
        for the startup screen. If that's true, I hope someone finds a patch
        for it. If not, there's a lot of initialization going down.

+ Change bars. Real, honest to god, decent, integrated change bars. You
can
        turn them on or off, reset them after every save, reset them on
        request, all sorts of things. You may not care about change bars,
        but once you've worked with them in a serious writing project,
        you'll hate to lose them. It's nice to be able to scan through and
        edit only those parts that have been changed, rather than having to
        search for all the new text (and probably missing some of it).

+ Bookmarks. In a large document (or even, for that matter, a small one)
how
        many times have you found yourself bouncing between two or three
        places, verifying one thing, rewriting another, checking to make
        sure the narritive matches in disparate parts of the story? On
        paper, you just keep the pages next to each other. On computers,
        you go crazy. Bookmarks let you set a pointer to a specific place in
        the document, and reference it by name. A "go to " label for your
        writing. I wish I'd thought of it.....

o Performance seems reasonable. Once it's started, that is. I'm also not
        hurting for memory. You have to have 1Meg to run it, 2 meg to run it
        with Multifinder. This won't work very well on a floppy system,
        either -- I wouldn't try less than a hard disk.

o Spell checker is on a part, probably a little better, than the Word
        checker. A little less powerful, a little more intuitive. Goodenuf,
        as they say.

o A thesaurus. I'm not terribly convinced a computer thesaurus buys you
        anything over a desk model (and the desk model is cheaper). But
        we'll see.

o Imports Write and Word files. Exports only Write files. Initially I
was
        bothered by this, but it makes sense. The Word 3.0 file structure
        is an amazing bitch to work with. And if you're exporting, you lose
        most of the special features -- and you're likely setting things up
        to import into another program that is also likely to read Write,
        not word files (or both). Macwrite is the primary text-transfer
        format for the Mac -- even Word reads it. So there's no real reason
        to export in anything else.

All in all, it looks to be a definite step up from Word 3.0. Easier to
use, a lot more writer friendly, a lot more intuitive. It is definitely,
definitely a word hacker's program, not for the casual writer. But it
set itself off for the high end, and it seems to have achieved it. This
is a first impression, though. I'll tell you more when I have a couple
of weeks under my fingers.

chuq

Chuq Von Rospach                        [e-mail]            Delphi: CHUQ

       I come to preach to a religion that doesn't exist. It has no
members.
          It has no clergy.  It has no doctrine. It has no collection
plate.


------------------------------

From: [e-mail] (David M. O'Rourke)
Subject: Re: FullWrite on shelves
Date: 9 May 88 16:34:04 GMT
Organization: Cal Poly State University -- San Luis Obispo

In article <[e-mail]> [e-mail] (Chuq Von Rospach) writes:
>I think so, so far. I picked up my copy at ComputerWare for about $260. I

  I agree I've been using the Pre-Release version since I got it, I
liked it better than word, even with the bugs.

>It's definitely not perfect, but it has the power of Word 3.0. It's also a

   It kind of grows on you, as you learn the program it keeps getting
better.

>There are some areas that I've flagged as things to be aware of. Some of
>these are plusses, some minuses. This isn't in any particular order (yet):

   It's there to support background pictures.  You can have FullWrite
print a picture on every page, or just the first page.  It's a simple
way to add fancy boarders or letter head to a document,  and since it's
a picture you don't have to worry about where it is in relation to text.

>+ They've implemented something called a variable. A more generalized flavor

   Variables are wonderful, when you insert a variable in several places
in the document, and then you want to change what the variable says, you
don't have to do a search and replace, you can just change it in the
variable dialog, and boom, all references to that variable are
automatically updated.  Try it it's real nice.

>- Startup is rather slow, and it brings up a copyright message every time.

   I agree, anyone at Ashton-Tate reading this.

  I love FullWrite!  I have found it to be more than very useful in the
past 5 months, and now the release version is out.  Thank god!

David M. O'Rourke
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| dorourke@polyslo | Disclaimer:  All opinions in this message are mine, but  |
|                  |              if you like them they can be yours too.     |
|                  |              Besides I'm just a student so what do I     |
|                  |              know!                                       |
|-----------------------------------------------------------------------------|
|    When you have to place a disclaimer in your mail you know it's a sign    |
| that there are TOO many Lawyer's.                                           |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


------------------------------

From: [e-mail]-rtl (Jim Sasaki)
Subject: Re: Mac Security
Date: 6 May 88 14:01:35 GMT
Organization: Siemens Research and Technology Labs, Princeton NJ

You might try SilverLining by LaCie.  It allows you to password-protect
a hard disk.  (It prevents you from mounting the disk until you enter
the password.) You can't circumvent this by booting from a floppy.

It also comes with a utility that lets you partition your disk into
separate logical volumes.  Different volumes can have different (or no)
passwords. The utility also lets you specify which (if any) volumes are
to be mounted at boot time.  A desk accessory lets you mount volumes
while you're in an application.  (So if you want, you can drag a
non-boot volume to the finder, get a cup of coffee, come back, and use
the desk accessory to remount the volume.)
--
Just a satisified customer, etc.

    -- Jim Sasaki ([e-mail])
--------------------
Any opinions above are my own, and not necessarily those of Siemens RTL, for
whom I consult.


------------------------------

From: [e-mail] (Ron Beloin)
Subject: Re: Programmer's Extender vs. MacExpress...
Date: 5 May 88 14:00:39 GMT
Organization: Ecosystems Research Center, Cornell University, Ithaca NY

In article <[e-mail]> [e-mail]
(Jeffrey A. Sullivan) writes:
>Has anyone had any experience with Programmer's Extender or MacExpress or
>any of these COMMERCIAL generic application/apptools kinds of products?  I
I purchased programmer's extender (Invention Software), both volumes I
and  II, to help me develope a relatively simple application. After
spending several frustrating days tracting down bugs in Invention
Software's code, I decided that I would have been better off without it.
There were several bugs, some of which would not allow procedures to
work at all, others  would cause data loss to the user of your program.
One by one I abandoned their code and wrote my own procedures. (In that
sense, it's a good  learning environment!) They don't give you all of
the sources, so I wa lucky that the bugs didn't show up in compiled code
(although they may yet). Now my app is about 5% Invention's code, and if
I ever do a major rewrite, I will purge all of it out.
--
 Ron Beloin, Ecosystems Research Center, Corson Hall, Cornell, Ithaca,NY 14853
 >> opinions << BITNET:BELOIN@CRNLTHRY; INTERNET:[e-mail]
 >> are mine << UUCP:{cmcl2,shasta,uw-beaver,rochester}!cornell!tcgould!beloin


------------------------------

From: [e-mail] (Alan Epstein)
Subject: PrintMgr Bug?
Date: 5 May 88 17:14:48 GMT
Organization: Meta Software Corporation, Cambridge MA

i think i may have discovered an elusive bug in the print manager, print
glue or printer drivers (notably but not restricted to the LW). all this
relates to Design/2.0 which is built using LightSpeed C (v2.15).

what i am doing is constructing an ordinary grafport which contains a
collection of boxes and polygons numbering less than 60. the polygons
are each about 38 bytes in size (about 6 vertices). when 'update' time
occurs, i write the objects to the device (screen or printer) using
FrameRect and FramePoly trap calls. all according to guidelines.

i have been able to construct cases where one or more of the polygons is
printed incorrectly -- part way thru the drawing, the polygon is drawn
to some incorrect position, indicating that the points vector had been
damaged. the next polygon is always fine. on the other hand, using the
same basic code, drawing the same set of polygons to the screen never
fails.

i have walked thru some of the print manager code and discovered that
when an offending polygon is being sent to the print driver (via
FramePoly), a call to PFDumpBuf() is invoked by PFOut() (both I assume
internal print manager or glue routines for which i have no
documentation). there appears to be a direct correlation between polygon
failures and calls to PFDumpBuf().

my hypothesis is that under certain circumstances, during a FramePoly
call, part of this polygon is written to the print port, the buffer
becomes full, requiring it to be flushed, and upon returning, PFOut is
no longer able to remember where it left off and writes some bogus
polygon segments for the remainder of the count.

this occurs on a Mac II (4Meg) or a Mac + (2Meg). it matters not whether
the polygons are locked prior to calling FramePoly (although i see that
FramePoly locks them anyway), nor is the presence of a printer idle
routine important.

although the problem manifests without any special debugging tools, it
is possible to exacerbate the failures (cause them where they were not
otherwise occurring), by using the TMON 'heap scramble' option. again,
the problem occurs without scramble.

i'm interested in learning from anyone who may have seen anything
remotely related to these bugs. i'd also like to hear from anyone at
apple who knows the internals of the printer manager & drivers since i
think that's where the problem lies.

feel free to call if you'd like further information.

        alan epstein
        meta software corp
        [phone]

        [ [e-mail] ] or
        [ bbn!metasoft!alan             ]


------------------------------

From: [e-mail] (Herb Weiner)
Subject: Re: MultiFinder switch bug with custom WDEFs
Date: 5 May 88 00:02:29 GMT
Organization: Tektronix, Inc., Beaverton, OR.

--------

Perhaps someone could explain the rationale for PROHIBITING a context
switch when a modal dialog box is in front.  I find that it would
sometimes be convenient to switch to the finder (for example) when a
sfGetFile dialog is active, so I could examine (for example) file
creation dates, sizes, etc.

It might be reasonable to require the application developer to take an
explicit action to ALLOW the context switch (such as providing an event
filter for the modal dialog).

Perhaps what I'm really suggesting is that modal dialogs are only modal
with respect to that application that displays them, but that they
should be MODELESS with respect to OTHER applications running under
MultiFinder.

If the real problem is that Apple depends upon non-reentrant code (such
as Standard File) which uses modal dialogs, perhaps we should all be
asking when Apple will make this code reentrant.

Looking forward to some enlightenment...

                                      Herb Weiner
                                      UUCP: !tektronix!midas!herbw
                                      AppleLink: D0521


------------------------------

From: [e-mail] (Phil Goldman)
Subject: Re: MultiFinder switch bug with custom WDEFs
Date: 5 May 88 20:01:51 GMT
Organization: Apple Computer Inc, Cupertino, CA

>Perhaps someone could explain the rationale for PROHIBITING a context switch
>when a modal dialog box is in front...

The rationale is one of user interface.  A modal dialog should be used
when the user must interact with it before the (visible) task can
continue.  If this is not its purpose, then the dialog should be
modeless.

>Perhaps what I'm really suggesting is that modal dialogs are only modal

There might be some use for dialogs that are modal within their layer.
This can already be accomplished by the applications themselves.
Hopefully these will not too often be used.

There has been some thought given to allowing the power user to override
modal dialogs, possibly by holding down the command key, or some
equivalent, while switching.

>If the real problem is that Apple depends upon non-reentrant code (such

And modeless too, right?  Why shouldn't other application windows be
allowed to be put in front of the StdFile dialog, as well as other
layers?  What's the distinction (besides a change to the app interface)?

Anyway... Do you really want multiple instances of StdFile?  I'd think
that it would be nicer to *never* have to use it.  In MultiFinder 6.0
(due real real soon now) it is possible to double-click on documents in
the Finder and have an running application open them anyway, thus
eliminating the need for StdFile (unless the latter is a preferred form
of navigation), especially if it is desirable to look at the file info
beforehand.
--
-Phil Goldman
Apple Computer


------------------------------

From: [e-mail] (Darin Adler)
Subject: Re: MultiFinder switch bug with custom WDEFs
Date: 7 May 88 07:21:04 GMT
Organization: Apple

In article <[e-mail]> [e-mail] (Marc T.
Kaufman) writes:
> One of the main reasons for using modal dialogs where modeless dialogs
> would do, is the availability of the Dialog Manager for handling most of
> the buttons, switches, and events.  If a dialog is modeless, you cannot
> use IsDialogEvent, NewDialog, GetNewDialog, or the ModalDialog event filter.

Absolutely untrue! IsDialogEvent, NewDialog, and GetNewDialog can all be
used with modeless dialogs. Note that for a modeless dialog, you create
the dialog and then return to the main event loop. Some of the events
you receive from GetNextEvent or WaitNextEvent need to be passed to the
dialog manager. After gettin an event, you call IsDialogEvent. If that
returns TRUE, then you call DialogSelect for the event. This is the
equivalent of what ModalDialog does for modal dialogs. Note that you can
do the same filtering that you would do in a ModalDialog event filter
just before calling DialogSelect. I even sometimes use the same dialog
filter for both modal and modeless dialogs like this:

    modal case:

        ... NewDialog ...

        ModalDialog(itemHit, @DialogFilter);

    modeless case:

        ... NewDialog ... {fall back to main event loop}

        ... GetNextEvent(everyEvent, event) ...
        IF IsDialogEvent(event) THEN BEGIN
            dialog := FrontWindow;
            hitSomething := FALSE;
            IF WindowPeek(dialog)^.windowKind = dialogKind THEN
                hitSomething := DialogFilter(dialog, event, itemHit);
            IF NOT hitSomething THEN
                hitSomething := DialogSelect(event, dialog, itemHit);
        ... {handle hits here} ...
        END;
--
Darin Adler                                             AppleLink:Adler4
UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin     CSNET: [e-mail]


------------------------------

From: [e-mail] (Phil Sohn)
Subject: Mac Lint
Date: 6 May 88 18:36:33 GMT
Organization: MIT Media Lab, Cambridge, MA

Does anyone know of a Lint type program for the Macintosh?

                                        [e-mail]


------------------------------

From: [e-mail] (Rob Beckham)
Subject: Turbo Pascal
Date: 6 May 88 15:45:42 GMT
Organization: The Unix(R) Connection, Dallas, Texas

After a couple of hours, of working with Turbo Pascal and my Mac II , I
have found that Font DA Juggler Plus causes Turbo to crash.  What
happensis that when you are running Juggler and you comply something to
memory, run your program  and come back to Turbo, Turbo will crash when
you touch the menu bar.

So don't use Juggler with Turbo.

Rob Beckham


------------------------------

From: [e-mail] (Dan Allen)
Subject: Re: Turbo Pascal
Date: 8 May 88 23:03:22 GMT
Organization: Apple Computer Inc, Cupertino, CA

Turbo Pascal 1.1 is great, but it DOES NOT WORK with MultiFinder.  It
seems to only have fixed the Mac II problems.

When a person Runs a program in Turbo, it creates a sub-heap inside its
own heap.  The original Mac II problem was that Color QuickDraw
allocated some data structure in this new heap when InitWindows was
called for the TTY window that Turbo puts up.  When Turbo returned to
its own heap and zapped the program heap, this data structure (which was
still being relyed upon by Color QuickDraw) caused a crash.

This has been fixed in Turbo 1.1.

However, running a program in Turbo under MultiFinder still crashes, not
just on Mac IIs, but on SEs and Pluses as well.  Unfortunately I cannot
recall the exact details of the problem, but it seems like it was
similiar to the above problem.

What you can do is build the program on disk (CMD K) and then run it.
That seems to work, but you lose some of the beauty of the Turbo
Environment.  I seem to recall a small notice by Borland to the effect
that this is the workaround for Turbo 1.1 and MultiFinder.

All Turbo needs to do is call _Launch with the appropriate high bit set
(documented in some recent TechNote if I recall right), and it would
work.

If there is a newer version of Turbo that does Run under MF, I should
would like to know!
--
Dan Allen
Software Explorer
Apple Computer


------------------------------

From: [e-mail] (Kent Hutson)
Subject: WDEFs in MPW?
Date: 7 May 88 06:17:43 GMT
Organization: Neurology, Baylor College of Medicine, Houston, Tx

I tried to write a WDEF in MPW and it didn't work.  Oddly, when that
same WDEF was compiled using Lightspeed Pascal, it worked fine. Could
anybody give me a clue how to make WDEF's in MPW? I would really like a
simple sample or fragments that I can figure out.

Thanks, Kent

--
Kent Hutson
Baylor College of Medicine, Houston, Texas
[e-mail]


------------------------------

From: [e-mail] (Lee Atchison)
Subject: LSC Glue code
Date: 6 May 88 22:55:44 GMT
Organization: HP Technical Networks, Cupertino, Calif.

Hi all.

Is there some way to change the "GLUE" that LSC generates when it is
making code (or device driver) resources?

The reason why I'm asking is that I want to be able to generate the
printer driver resources "PDEV" (I think that's what they are called),
and these resources require the first four words to be offset to certain
routines. As far as I can tell, the standard LSC glue doesn't support
this.

Can anyone help me?

                        -lee
--
Lee Atchison
Hewlett Packard, Business Networks Division
Cupertino, CA 95014
[e-mail]

------------------------------

End of Usenet Mac Digest
************************

ACTION>